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1 INTRODUCTION 

AirSTAR [17, 2] is an integrated flight test infrastructure which utilizes remotely piloted, 
powered subscale models for flight testing developed at NASA’s Langley Research Center 
(LaRC). When flying, commands from the ground-based pilot are broadcast to the aircraft 
and telemetry data from the aircraft are broadcast to the ground station. The goal of this 
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work is to design and verify a communication protocol that satisfies AirSTAR’s safety and 
operational requirements: 

• It is of paramount importance that commands from the pilot be treated by the com- 
munication system as urgent. That is, they are to be broadcast to the aircraft as soon 
as possible and should be processed at the aircraft with all due speed. This means 
that there should be no buffering of these data at either the sender or receiver. This 
requirement is called as the weak delivery requirement since data lost in transmission 
should not be retransmitted as they would be considered stale by the time they arrived 
at the pilot. 

• Engineers on the ground need to receive all telemetry data produced by the aircraft in 
order to analyze aircraft performance as well as to plan future aircraft flights. In con- 
trast to the previous case, the protocol should guarantee that all of telemetry data are 
eventually delivered. This requirement is called as the guaranteed delivery requirement. 

Since the requirements of weak and guaranteed delivery are in some sense orthogonal to 
each other, we can structure the solution as two different protocols: the weak delivery proto- 
col (WDP) and the guaranteed delivery protocol (GDP). In addition to these two protocols, 
other protocols are needed to support communication between the aircraft and ground sta- 
tion. As usual in protocol design, this collection of protocols is structured in a protocol stack 
(see Figure 1). 

This document contains a description of a protocol that satisfies both the weak deliv- 
ery and the guaranteed delivery requirements. This protocol is intended for the AirSTAR 
remotely operated vehicle. In addition to the high-level description of the protocol stack, 
we provide an overview of its formal specification and verification. For readability pur- 
poses, we use standard mathematical notation as much as possible. However, the math- 
ematical development presented here has been formally specified and verified in the Pro- 
totype Verification System (PVS) [19]. This development is electronically available from 
http : //research .nianet . org/fm-at-nia/AirSTAR. 

Section 2 gives a brief overview of the protocol stack. The layers of the protocol stack, 
i.e., application layer, WDP, GDP, and link layer, are specified in Section 3. Section 4 shows 
how sender and receiver processes, that conform to the stack protocol, are specified. The 
formal verification that the proposed protocol satisfies the weak and guaranteed delivery 
requirements is described in Section 5. 

2 PROTOCOL STACK 

Protocols are generally structured in layers, where each layer handles a different aspect of 
message processing [24], As a message moves down the stack, each layer performs some 
processing and adds packet headers. As a message moves up the stack, the corresponding 
packet headers are removed. The classic ISO seven layers model partitions the stack into 
a physical layer, link layer, network layer, transport layer, session layer, presentation layer, 
and application layer. Protocols for embedded systems used in the aerospace arena are 
usually not sophisticated enough to warrant but a few layers. For instance, in our case, 
the protocol simply broadcasts information so there is no need for a network layer, which 
performs routing. The layers of our protocol stack roughly correspond to the application 
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Figure 1: Protocol stack 


layer, transport layer, link layer, and physical layer. Given that we do not currently have any 
details about the physical layer, it will not be explicitly modeled in this document. However, 
we do model an abstract communication medium that we call ether. 

The proposed protocol stack is composed of the four layers illustrated in Figure 1. At the 
top is the application layer. The AirSTAR flight-computer software as well as the ground- 
control software are presumed to reside here. All messages sent from the application layer are 
sent via either WDP or GDP depending on whether weak or guaranteed delivery is required. 
The application is assumed to decide which protocol is used to send which type of message. 
The next layer down corresponds to the transport layer and it is here that the WDP and 
GDP protocols reside. WDP simply sends a message, but provides no guarantee that the 
message ever arrived at its destination. Hence, messages may be lost or corrupted in transit 
and are never resent. GDP is designed to provide its user with a guarantee that any message 
sent is eventually received, and that they are received in the same order they are sent. The 
differences between WDP and GDP are similar to the differences between UDP and TCP, 
but both are considerably simpler. The link layer is the next layer in our protocol stack. 
Note that the WDP and GDP protocols directly interface with the link layer as there is no 
network layer. The link layer performs error detection and multiplexes outgoing messages 
from the WDP and GDP layers and demultiplexes the incoming messages. The last layer is 
the ether, which correspond to the communication medium. 

3 SPECIFICATION OF PROTOCOL LAYERS 

In our model, the protocol layers are connected using First-In First-Out (FIFO) queues. 
In Figure 1, each queue is represented by a small rectangle with an arrow pointing in the 
direction of the information flow. The queues are named x_to_y indicating that the data 
moves from layer x to layer y. The names of the queues are given as follows: 


App_to_WDP 

WDP_to_App 

App_to_GDP 

GDP_to_App 

WDP_to_LL 

LL_to_WDP 

GDP_to_LL 

LL_to_GDP 
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The WDP_to_LL, LL_to_WDP, GDP_to_LL, and LL_to_GDP queues form the link interface (see 3.4). 

In PVS, these queues are defined as finite sequences, i.e., a record with two fields: length, 
which contains the length of the queue, and seq an array indexed by 0 . . . length — 1 con- 
taining the data. The top of the queue is indexed by 0. Although an implementation would 
most likely adapt a more efficient scheme than FIFO queues, the behavior of frames moving 
from one layer to another would remain the same. 

The ether, which represents the communication medium, interacts with the protocol 
stack through two unidirectional communication channels: the input channel that flows 
from the protocol stack to the medium, and the output channel that flows from the medium 
to protocol stack. The input and output channels form the ether interface (see 3.5). In 
PVS, these channels are defined as bags, i.e., multisets reflecting the possibility of duplicate 
messages and out of order delivery. 

Before examining each layer in some depth, let us illustrate how a message sent via WDP 
flows down the stack, over the ether, and back up the stack. The node sending the message 
is denoted as the sender and the node receiving the message is denoted the receiver. The 
sender’s application layer places the message into the App_to_WDP queue. The WDP layer 
processing removes it and places it into the WDP_to_LL queue. The link layer will remove this 
and place it into ether input. The link layer at the receiver will remove this message from 
the ether output and place it into the receiver’s LL_to_WDP queue. The receiver’s WDP layer 
will process the message placing it in the WDP_to_App queue from which the application on 
the receiving side removes it for processing. 

3.1 Application Layer 

The application layer is where all user and flight computer applications reside. We do not 
know what specific applications currently exist or what applications may be created in the 
future so this layer is treated quite abstractly as is traditional in the networking community. 
This layer may be composed of many processes, but we assume that at both the ground 
station and the aircraft, only a single process handles the processing of incoming messages. 
This simplification is realistic based on the current operation of the aircraft and allows us to 
forgo a complex socket-like mechanism. 

In PVS, the application layer is modeled as two pairs of queues. The App_to_WDP queue 
at the sender that contains the data that must be sent in a timely fashion, e.g., via WDP, 
and the APP_to_GDP queue containing data that must be sent reliably, e.g., via GDP. The 
WDP_to_APP and GDP_to_APP queues hold data that have been received from WDP and GDP, 
respectively. It is assumed that the initial state of App_to_WDP and APP_to_GDP at the sender 
contain all of the data that will be sent and the WDP_to_APP and GDP_to_APP queues at 
the receiver are empty. This allows us to formulate a correctness criteria for the weak 
delivery protocol and the guaranteed-delivery protocol in terms of relations stating that the 
WDP_to_APP queue in the receiver side is a subset of the App_to_WDP queue when the sender 
was in its initial state and that the GDP_to_APP queue in the receiver side is a prefix of the 
App_to_GDP queue when the sender was in its initial state. The use of the initial state of 
the sender in this formulation is necessary because the queues will have data removed as the 
protocol executes. 
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3.2 Weak Delivery Protocol (WDP) 

WDP is designed to satisfy the weak delivery requirement. The goal is to send and deliver 
messages to and from the application level as promptly as possible. In this application 
domain, stale data is useless so if a message is corrupted or lost in transmission it should 
not be resent. Nor should messages be buffered at either the sender or the receiver. This 
is a very basic protocol that simply moves data from the application layer to the link layer 
without really performing any processing. The sender and receiver are modeled as separate 
processes. 

The state of WDP sender is defined as 

WDPSender = App_to_WDP : f if o [Data] x 
link : Linklnterf ace x 
ether : Etherlnterf ace x 
nop : Boolean, 

forming a tuple of the queue containing data to be sent, an interface to the link layer holding 
the WDP_to_LL and LL_to_WDP queues, an interface to the ether, and a Boolean that is true 
if no action is taken. 

The WDP sender protocol is defined as a state transition function that maps the current 
WDP sender state to the next state: 

WDPSenderNext : WDPSender — » WDPSender. 

The function behaves as follows. If the App_to_WDP queue is nonempty, then remove the next 
message from App_to_WDP and add it to the WDP_to_LL queue in the link interface. 

The state of the WDP receiver is defined as 

WDPReceiver = WDP_to_App : f if o [Data] x 
link : Linklnterf ace x 
ether : Etherlnterf ace x 
nop : Boolean, 

forming a tuple of the queue where the received data will be placed, an interface to the link 
layer holding the WDP_to_LL and LL_to_WDP queues, an interface to the ether, and a Boolean 
that is true if no action is taken. 

The WDP receiver is defined as a state transition function that maps the current WDP 
receiver state to the next state: 

WDPReceiverNext : WDPReceiver — > WDPReceiver. 

The function behaves as follows. If the LL_to_WDP queue in the link interface is nonempty, 
then remove the next message from that queue and add it to the WDP_to_App queue. 
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3.3 Guaranteed Delivery Protocol (GDP) 

GDP is designed to satisfy the guaranteed delivery requirement. Intuitively, GDP should 
ensure that messages are delivered in the same order as they are sent. In order for the sender 
to know that a message has been received, the recipient must send back an acknowledgment. 
In protocols such as TCP, this acknowledgment is often piggybacked on a message sent to 
the original sender rather than using a dedicated acknowledgment. Given that a significant 
percentage of the traffic flow will be from the aircraft to the ground station, this does not 
seem like the best design choice. In addition, rather than acknowledging a single message, 
it seems more appropriate to acknowledge receipt of a contiguous block of data since this 
keeps down the number of acknowledgment packets, which is desirable in this application 
domain. Hence, GDP is a sliding- window protocol [24] with block acknowledgment [9]. 

3.3.1 Sliding- Window Protocol 

In general, sliding-window protocols have the following characteristics: 

• Each message has a sequence number that acts as an identifier. 

• The protocol receiver process acknowledges the receipt of data messages by sending an 
acknowledgment message to the sender. 

— If the sender has not received an acknowledgement that a message has been re- 
ceived in a predefined time, then a timeout will occur and the protocol will resend 
that message. 

— If a receiver has already received and acknowledged a message, but the same 
message (defined as having same sequence number) is received again, then the 
system will resend the acknowledgement, but nothing is done with the data since it 
has already been processed. This covers the situation where an acknowledgement 
message is lost or corrupted in transit and the sender resends a message. 

• There is an upper bound sw on the number of data messages that can be sent without 
receiving acknowledgment for any of them. There is also an upper bound rw on the 
number of data messages that can be received without sending an acknowledgment. 
The value of rw should be chosen so that rw < sw. The value sw is called the sender’s 
window size and the value rw is called the receiver’s window size. 

The protocol sender maintains a bounded buffer called ackd. This buffer has two fields: 
a data held and a Boolean mask held. The GDP protocol moves data from the App_to_GDP 
queue to the ackd buffer’s data held when it is to be broadcast and initializes the mask held 
to false. The buffer index indicates the sequence order in which messages are sent. Each 
data entry is broadcast to the destination, which, at some point in time, sends a response 
acknowledging the receipt of some contiguous block of sequence numbers. The mask values 
are set to true for those data entries that have been acknowledged. 

The variable ns is a pointer to the sequence number of the next data item to be sent and 
the variable na is a pointer to the hrst sequence number that has yet to be acknowledged. 
That is, sequence numbers 0 , . . . , na — 1 have all been acknowledged as received by the 
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sender, but sequence number na has not yet been acknowledged. An invariant na < ns < 
na + sw is maintained by the sender saying that the window of sent but not acknowledged 
data is of size at most sw. The sender will not send messages with a sequence number 
greater than na + sw until data message na is acknowledged. The sender may receive 
acknowledgments for sequence numbers s, where na < s < ns, in any possible order; yet, 
only when acknowledgments for the contiguous sequence numbers na, . . . , x, where x < ns, 
have been received, is the value of na slid forward to x + 1. 

The receiver also maintains a bounded buffer rcvd containing data received from the 
sender. The protocol moves data sent by the sender from the LL_to_GDP queue into the 
rcvd buffer and sets the mask value at that position to true. The data is indexed by the 
sequence numbers. The variable la points to the last acknowledged sequence number, i.e., 
acknowledgment messages have been sent for sequence numbers 0, . . . , la — 1. The variable nd 
points to the lowest sequence number that has yet to be delivered to the GDP_to_App queue. 
The variable Ir points the highest sequence number that has been received and Ir < nd + rw. 
The receiver ignores messages with sequence numbers greater than nd + rw. When the 
receiver has received the contiguous block of sequence numbers nd, . . . ,x, the pointer nd is 

slid forward to x + 1. Note that messages la, ,nd — 1 have been received, but not yet 

acknowledged. Periodically, GDP sends an acknowledgment message that acknowledges the 
receipt of messages la, . . . , nd — 1 and la is reset to nd. 

Let us illustrate how the protocol works using the example from Figure 2. Assume that 
the sequence numbers 1, 2, and 3 have been sent and acknowledged so na = 4 and la = 4. 
From the diagram we see that sequence numbers 4, . . . , 12 have been sent, but have not 
necessarily been delivered to the receiver. Assume that sequence numbers 4 and 5 have been 
sent and received, but not yet acknowledged. Let us also assume that 9, 10, and 11 are 
delivered to the GDP receiver process, but 6, 7, and 8 were lost in transit. At some point the 
sender times out and resends these messages. This situation is illustrated in Figure 2. When 
sequence numbers 4, . . . , 11 have been received by the receiver, the pointer nd slides forward 
to 12. When the acknowledgment message is sent by the receiver acknowledging the receipt 
of the sequence numbers 4, . . . , 11 the receiver now sets la to 12. If the acknowledgment is 
lost in transit, the sequence numbers 4, . . . , 11 would eventually be resent and, although the 
messages would be ignored, acknowledgments would be resent. 

3.3.2 Bounded Buffers 

In PVS, we model the windows ackd and rcvd as bounded buffers. The parameter maxsize 
defines the upper-bound on the length of the buffer. The type definition for our buffer is as 
follows: 


Window = 

x 

x 


length :0 < length < maxsize 
mask : {s : ARRAY[(0, . . . , maxsize — 1) — > Boolean] 

| V(i : (length, . . . , maxsize — 1)) : -i s(i)} 
data: ARRAY[(0, . . . , maxsize *-!)—>■ Data] 



where mask is a finite sequence of Boolean values and data is a finite sequence of data. Both 
sequences are indexed by an integer value of at most maxsize — 1. The protocol only cares 
about data indexed by 0, . . . , length — 1. In particular, we assume that mask(i) is equal 
to false for % > length. In the case of the ackd buffer, mask(i) is true if and only if an 
acknowledgment has been received by the sender for sequence number na + i. In the case 
of the rcvd buffer, mask(i) is true if and only if a message has been received by the receiver 
with the sequence number nd + i. 

Recall that when acknowledgments for sequence numbers na, . . . , x have been received, 
na is slid forward to x + 1 and similarly when messages with sequence numbers nd , . . . , y 
have been received, nd is slid forward to y + 1. The process of readjusting the window is 
handled by the two functions first_false and slide. The function firstxfalse returns 
/ such that value of the buffer’s mask at 0, ...,/ — 1 are all true, but the mask value at / 
is false. The lower pointer, either nd or na , of the buffer is moved to the first-false value /. 
The function slide takes as parameters a buffer of length n and an index to the first false 
in that buffer / and returns a new buffer of size n — f where index i in the new buffer holds 
the contents of index i + f in the old buffer. So as long as / > 0, the new buffer has a length 
smaller than the original. 

In an actual implementation, the bounded nature of the buffer would be handled some- 
what differently because sequence numbers must also be bounded. The traditional solution 
is to use modulo arithmetic, but this greatly complicates the complexity of the model and 
we feel that our design decision to model the finite buffer as we did is a reasonable modeling 
trade-off. 

3.3.3 Sender 

The sender process implements the procedure for the sliding window protocol sender outlined 
above. The window ackd is implemented as an instance of Window. The state of the sender 
is defined as 


GDPSender = App_to_GDP : f if o [Data] x 

winsender : WinSenderPrivate x 
link : Linklnterf ace x 
ether : Etherlnterf ace x 
nop : Boolean, 

forming a tuple of the queue holding data to be sent, the local pointers and bounded buffers 
of the sender side of the sliding-window protocol, the interface to the link layer containing 
the two queues GDP_to_LL and LL_to_GDP, the interface to the ether, and a Boolean that is 
set to true if no action is performed. 

The sender process is modeled as a state transition function that takes the current state 
of the GDP sender and an action to be performed, and returns the next state: 

GDPSenderNext : GDPSender x GDPSenderAction — > GDPSender. 

The possible actions performed by the sender are send a message, process an acknowledg- 
ment, and timeout due to the fact that an acknowledgment has not been received in a 
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predefined time. The actions are formally defined by the enumeration type: 


GDPSenderAction = {Send, GetAck, Timeout}. 

The following describes GDP sender transition to the next state. In each case, the next 
state is the same as the current state except for the changes described below. 

Send. If there is data to be sent and space in the sender window, i.e., 

-i empty_f if o?(App_to_GDP) A ns — na < sw, 

then 


• If there is no space in the ackd sender window, then the next state is the same as 
the current state except that nop is set to true. 

• The data is removed from the App_to_GDP queue. 

• A GDP frame is formed from the value removed from App_to_GDP and the sequence 
number ns and added to the GDP_to_LL queue to send it to the link layer for further 
processing. 

• ns is incremented by 1. 

• ackd is updated, i.e., its length is incremented by 1. 

• data(n) is assigned the value of the data removed from the queue and mask(n) is 
assigned the value false, where n is the current length of the buffer. 

GetAck. An acknowledgment message contains two fields, lb and ub , that denote the lower 
bound and upper bound on the sequence numbers being acknowledged. If the message 
being acknowledged falls outside of the window 

lb < na V ub > ns, 

then ignore the message removing it from the LL_to_GDP queue. 

If 

na < lb Aub < ns, 

then the next state is the same as the current state with the acknowledgment message 
removed from the LL_to_GDP. The ackd mask entries lb — na, . . . ,ub — na are set to 
true. The function slide is then invoked to change ackd as described above. 

Otherwise, nop is set to true. 

Timeout. If a timeout has occurred, because an acknowledgement has not been received 
within the predetermined limit, and ns > na, then retransmit data(O), from ackd, 
which corresponds to the message with the sequence number na. Otherwise, the next 
state is the same as the current state except that nop is set to true. 
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3.3.4 Receiver 

The receiver process implements the procedure for the sliding window protocol receiver 
outlined above. The window rcvd is also an instance of Window. The state of the sender is 
defined as 


GDPReceiver = GDP_to_App : f if o [Data] x 

winreceiver : WinReceiverPrivate x 
link : Linklnterf ace x 
ether : Etherlnterf ace x 
nop : Boolean. 

This forms a tuple of the queue that will hold the data once it has been received, the local 
pointers and bounded buffers of the receiver side of the sliding-window protocol, an interface 
to the link layer holding the queues GDP_to_LL and LL_to_GDP, an interface to the ether, and 
a Boolean that is set to true if no operations are performed. 

The receiver process is modeled as a state transition function that takes the current state 
of the GDP receiver and an action to be performed, and returns the next state: 

GDPReceiverNext : GDPReceiver x GDPReceiverAction — > GDPReceiver. 

The possible actions performed by the receiver are to receive a message or to send an ac- 
knowledgment. The actions are formally defined by the type enumeration: 

GDPReceiverAction = {Receive, Sendack}. 

The following describes GDP receiver transition to the next state. In each case, the next 
state is the same as the current state except for the changes described below. 

Receive. If the message on the top of the LL_to_GDP queue is not a data message, then nop 
is set true. If a data message is on the top of the LL_to_GDP queue, then set a local 
variable idx to the value of this message’s sequence number. Depending on the value 
of the sequence number, the protocol takes the following action: 

• If idx > nd + rw V la < idx A idx < nd , then the message is removed from the 

LL_to_GDP. 

• If idx < la, which means that the message has already been acknowledged, but 
for whatever reason the sender has resent it, then send an acknowledgment back. 
That is, the message removed from the LL_to_GDP queue and the acknowledgment 
added to the GDP_to_LL queue. 

• If nd < idx < nd + rw, then the sequence number is within the window and so 
the data is placed in the rcvd buffer at location idx — nd and the mask set to 
true. 

— The message is removed from the LL_to_GDP queue. 

— The message is added to the GDP_to_App queue. 
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— nd is set to the index of the first mask in rcvd that is false. 

— Ir is set to the maximum between Ir and idx + 1. 

— rcvd is slid as explained above. 

SendAck. If nd > la, then form an acknowledgment message acknowledging la, . . . ,nd— 1. 
The next state is the same as the current state except that 

• la is set to nd 

• The new acknowledgment message is added to the GDP_to_LL queue. 

3.4 Link Layer 

The link layer is intended to serve as an interface between the WDP and GDP layers and 
the physical layer. It provides common services needed by WDP and GDP such as error 
detection. Although the details are elided in our specification, the assumption is that a 
function is applied to an outbound message generating a checksum or some other such value. 
The message is then wrapped in a link layer header containing the error-detection code. 
The link layer also multiplexes messages sent from the WDP and GDP layers wrapping 
them in the common header and demultiplexes them on the receiving side removing this 
header and sending the unwrapped frame to the appropriate protocol for processing. The 
communication medium is assumed to be unreliable so just because a message was sent by 
the link layer does not mean that it will arrive. Also note that the communication medium 
may corrupt a message, hence the need for the checksum held. A message that is corrupted 
in transit will be dropped. 

A link layer frame is composed of a checksum and a disjoint sum of a GDP or a WDP 
frame: 


LinkFrame : = cs : Checksum x 

frame : GDPFrame + WDPFrame, 

where + denotes disjoint sum. The type Checksum is defined as a nonempty uninterpreted 
type. 

Linklnterf ace represents the interface that the link layer provides to the higher layer 
and is defined as a tuple of FIFO queues holding LinkFrame data. The structure is defined 
as follows: 

The state of the link layer is defined as the following triple: 

Link = link : Linklnterf ace x 

ether : Etherlnterf ace x 
nop : Boolean. 

The link layer processing is modeled as a state transition function that given the current 
state and an action to perform, returns the next state for the link layer 

LinkNext : Link x LinkAction — » Link. 
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The transition function performs the following actions: send a GDP message, send a WDP 
message, and receive a message. Formally, the actions are defined by the type enumeration: 

LinkAction = {SendWDP, SendGDP, Receive}. 


Note that the 

SendWDP. Broadcast the frame located on the top of the WDP_to_LL queue to the receiver, 
i.e., 

• Remove the WDP frame, say frame, from the WDP_to_LL queue. 

• Create a link frame as the product of frame and the frame’s checksum. 

• Place the linkframe in the ether. 

SendGDP. Broadcast the fame located on the top of the GDP_to_LL queue to the receiver, 
i.e., 

• Remove the GDP frame, say frame, from the GDP_to_LL queue. 

• Create a link frame as the product of frame and the frame’s checksum. 

• Place the linkframe in the ether. 

Receive. Let linkframe be the link layer frame removed from the ether, 

• If the checksum on the linkframe is not valid, then the next state is the same as 
the current state except that nop is set to true. 

• If the linkframe is a GDP message, then add the GDP frame to LL to GDP queue 
and remove linkframe from the ether. 

• If the linkframe is a WDP message, then add the WDP frame to LL_to_WDP 
queue and remove linkframe from the ether. 

3.5 Ether 

The ether is an unreliable communication medium where messages can sometimes be du- 
plicated, dropped, or corrupted by noise. Our model reflects the unreliable nature of the 
medium. 

The Etherlnterf ace is specified as follows: 

Etherlnterf ace = input : bag [LinkFrame] x 

output : bag [LinkFrame] . 

The link layer sends messages by placing link frames into its ether input channel and receives 
frames on its ether output channel. In practice, a node acting as a sender places information 
on its input channel so that same channel must be the output channel at the receiver. 

The state of the ether layer is defined as the following triple: 

Ether = ether : Etherlnterf ace x 
nop : Boolean. 
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Ether processing is structured as a state transition function that given the current state and 
an action to be performed, returns the next state: 


EtherNext : Ether x EtherAction — > Ether. 

The transition function may drop, duplicate, or corrupt messages. The actions are formally 
defined by the following enumeration type: 

EtherAction = { Dropln, DropOut, Dupln, DupOut, Noiseln, NoiseOut }. 

Dropln. Drop a specified frame in the input channel by removing that frame from the input 
multiset. 

DropOut. Drop a specified frame in the output channel by removing that frame from the 
output multiset. 

Dupln. Duplicate a specified frame in the input channel by adding an additional copy of 
the frame to the input multiset. 

DupOut. Duplicate a specified frame in the output channel by adding an additional copy of 
the frame to the output multiset. 

Noiseln. A noise corrupted frame is added to the input channel. 

NoiseOut. A noise corrupted frame is added to the output channel. 

4 SPECIFICATION OF SENDER AND RECEIVER PROCESSES 

Thus far, we have described each layer of the protocol stack individually. In this section, 
we show how these layers are composed to form a protocol stack. First, we will look at the 
WDP and GDP protocols in isolation and then we shall see how these two protocols can be 
composed asynchronously. 

For each one of the WDP and GDP protocols, we will assume that we have two processes: 
a sender process and a receiver process. The WDP sender and receiver processes are called 
WDPSender? and WDPReceiver?, respectively. Similarly, the GDP sender and receiver pro- 
cesses are called GDPSender? and GDPReceiver?, respectively. These processes behave in a 
non-deterministic way. Hence, each one of them is defined as relation between the current 
state and one of the possible next states. 

For instance, GDPSender?, which relates the current state of the GDP sender process and 
a possible next state, is defined as either a GDPSenderNext transition, a LinkNext transition, 
or a EtherNext transition, where the fields that are not modified by the transitions remain 
unchanged. As explained in Section 3, each one of these transitions depends upon a par- 
ticular action. In order to model the non-deterministic nature of actions, we use existential 
quantifiers to generate actions for each transition. The relation GDPSender? is formally 
expressed as follows: 

GDPSender? (s, n : GDPSender) = (3a: GDPSenderAction. n = GPDSenderNext(s, a) 

A -is‘nop A -in‘nop 
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V 


(3a: LinkAction. ri; = LinkNext(s;, a) 

A -is; ‘nop A ‘nop 

A n‘App to GDP = s‘App_to_GDP 
A s‘winsender = n‘winsender ) 

V 

(3a: EtherAction. n e = EtherNext(s e , a) 

A -is e ‘nop A -in e ‘nop 
A n‘link = s‘link 
A n‘App to GDP = s‘App_to_GDP 
A s‘winsender = n‘winsender ), 

where s and n stand for the current and next GDPSender state, respectively, and the back- 
quote symbol is the held access operator. We denote by sub-indices l and e the projections 
of states s, n into Link and Ether states, respectively. 

The relations GDPReceiver?, WDPSender?, and WDPReceiver? are defined in a similar 
way. 


GDPReceiver?(s, n : GDPReceiver) = (3a: GDPReceiverAction. n = GPDReceiverNext(s, a) 

A ->s‘nop A ->n‘nop 

V 

(3a: LinkAction. n; = LinkNext(s;, a) 

A ->s;‘nop A -in;‘nop 
A n‘GDP_to_App = s‘GDP_to_App 
A s‘winreceiver = n'winreceiver ) 

V 

(3a: EtherAction. n e = EtherNext(s e , a) 

A -is e ‘nop A -in e ‘nop 
A n‘ link = s‘link 
A n‘GDP_to_App = s‘GDP_to_App 
A s‘winreceiver = n‘winreceiver ). 


WDPSender? (s, n : WDPSender) = 


V 


( n = WDPSenderMext(s) 

A ->s‘nop A -in‘nop 

(3a: LinkAction. n; = LinkNext(s;, a) 
A ->s;‘nop A -in;‘nop 
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A n‘App_to_WDP = s‘App_to_WDP ) 

V 

(3a: EtherAction. n e = EtherNext(s e , a) 

A -is e ‘nop A -in e ‘nop 
A n‘link = s'link 
A n‘App_to_WDP = s‘App_to_WDP ). 

WDPReceiver?(s, n : WDPReceiver) = ( n — WDPReceiverNext(s) 

A -<s‘nop A -in‘nop 

V 

(3a: LinkAction. n/ = LinkNext(s/, a) 

A -iS;‘nop A -in/‘nop 
A n‘WDP_to_App = s‘WDP_to_App ) 

V 

(3a: EtherAction. n e = EtherNext(s e , a) 

A -is e ‘nop A -in e ‘ nop 
A n‘link = s' link 
A n‘WDP_to_App = s‘WDP_to_App ). 

We define a sender process, which conforms to the protocol stack, as the asynchronous 
composition of the WDP and GDP sender processes. Formally, the state of the sender 
process is the union of the fields in WDPSender and GDPSender: 

Sender = App_to_GDP : f if o [Data] x 
App_to_WDP : f if o [Data] x 
winsender : WinSender x 
link : Linklnterf ace x 
ether : Etherlnterf ace. 

The relation between the current state of the sender and a possible next state is as either a 
WDPSender? transition or a GDPSender? transition. As in the previous relations, fields that 
are not modified by the transitions remain the same: 

Sender? (s, n : Sender) = WDPSender ? (s ws , n ws ) 

A s‘App_to_GDP = n‘App_to_WGDP 
A Awindsender = rfiwinsender 

V 

GDPSender?(s ffS , n gs ) 

A s‘App_to_WDP = n‘App_to_WDP. 
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We denote by sub-indices ws and gs the projections of states s, n into WDPSender and 
GDPSender states, respectively. 

In a similar way, the receiver process is defined as the asynchronous composition between 
the WDP and GDP receiver processes. Formally, 

Receiver = GDP_to_App : f if o [Data] x 
WDP_to_App : f if o [Data] x 
winreceiver : WinReceiver x 
link : Linklnterf ace x 
ether : Etherlnterf ace. 

Receiver?(s, n) = WDPReceiver?(s TOr , n wr ) 

A s‘GDP_to_App = n‘GDP_to_App 
A s‘windreceiver = rbwinreceiver 

V 

GDPReceiver?(s 9r , n gr ) 

A s‘WDP_to_app = n‘WDP_to_app, 

where sub-indices wr and gr denote the projections of states s,n into WDPReceiver and 
GDPReceiver states, respectively. 

5 PROTOCOL VERIFICATION 

In this work, we focus on the functional correctness of a distributed system that consists of 
a sender node and receiver node communicating via our protocol stack through the ether. 
Each node has both the GDP and WDP processes, but for the sake of analysis we consider 
a sender and receiver and assume that they are located at different nodes. We denote that 
system by WDP || GDP. The system configuration is illustrated by Figure 3. 

5.1 Distributed System 

We formally specify the distributed system WDP || GDP as a state transition system using a 
set of PVS theories developed by Rusu [21]. In those theories a state transition system is 
defined by an initial set of states and a state transition relation. The set of reachable states 
is the set of states in the reflexive-transitive closure of the transition relation starting from 
the set of initial states. The functional correctness of a system specified this way is expressed 
by invariant properties, i.e., predicates that hold in every reachable state of the system. 

Formally, the state of WDP || GDP, namely WDP_GDP, is composed of the union of fields in 
Sender and Receiver, where the ether interface is shared between the two processes: 

WDP.GDP = App_to_GDP : f if o [Data] X 
App_to_WDP : f if o [Data] x 
GDP_to_App : f if o [Data] x 
WDP_to_App : f if o [Data] x 
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Figure 3: Sender/Receiver processes 


winsender : WinSender x 
winreceiver : WinReceiver x 
linksender : Linklnterf ace x 
linkreceiver : Linklnterf ace x 
ether : Etherlnterf ace. 

At the initial states, the queue App_to_GDP contains the data to be sent using GDP and the 
queue App_to_WDP contains the data to be sent using WDP. All the other queues and the 
ether channels are empty. 

The transition relation of WDP || GDP is defined as either a Sender? transition or a 
Receiver? transition, where the fields that are no modified by the transitions remain the 
same: 


WDP_GDP?(s,n : WDP.GDP) = Sender ?(s s ,n a ) 

A s‘GDP_to_App = n‘GDP_to_App 
A s‘WDP_to_App = n‘WDP_to_App 
A s‘winreceiver = n‘winreceiver 
A s‘linkreceiver = n'linkreceiver 

V 

Receiver?(s r , n r ) 

A s‘App_to_GDP = n‘App_to_GDP 
A s‘App_to_WDP = n‘App_to_WDP 
A s‘winsender = n'winsender 
A s‘linksender = ?z‘linksender. 
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The sub-indices s and r denote the projections of states s, n into Sender? and Receiver? 
states, respectively. In the case of s r and n r the input and output channels of the ether are 
exchanged, i.e., 


s r ‘ ether 1 input 
s r ‘ ether 1 output 
n r ‘ ether 1 input 
n r L ether 1 output 

The invariant predicate that expresses 
follows: 


s s ‘ether‘output, 
s s ‘ether‘input, 
n s ‘ ether ‘output, 
n s ‘ether‘input. 

correctness property of WDP is defined as 


the 


WDP_sound(s, Sq : WDP_GDP) = s‘WDP_to_App C So‘App_to_WDP, 


where s refers to a reachable state of the distributed system and So refers to an initial state. 
This invariant states that WDP data that the receiver process delivers to the application 
layer were indeed sent by the sender’s application layer. 

The invariant predicate that expresses the correctness property of GDP is defined as 
follows: 


GDP_sound(s, So : WDP_GDP) = s‘GDP_to_App ■< So‘App_to_GDP, 

where is the prefix relation between sequences. This invariant states that GDP data are 
delivered by the receiver to the application layer in the same order as they were sent by the 
sender’s application layer. 

Our verification objective is to formally prove that these two predicates, WDP.sound and 
GDP_sound, are indeed invariants of the distributed system WDP || GDP. A direct proof of these 
properties can be accomplished by strengthening the invariant to a form that can be proved 
by induction on the length of reachable traces, for example using the PVS theories provided 
in [21]. However such a proof is extremely cumbersome since it requires a case analysis 
of more than 600 cases, which correspond to all possible interleavings between sender and 
receiver processes of WDP and GDP. 

Instead of a direct proof, we propose a compositional approach where each invariant is 
independently proved for its respective system, i.e., WDP.sound is an invariant of WDP and 
GDP.sound is an invariant of GDP, and then we provide a general framework that enables to 
lift these invariants to the distributed system WDP || GDP. 

5.2 Proving Invariants on WDP and GDP 

We first consider the case of a system of a sender and receiver WDP processes. The state 
of this system, called WDP, is a tuple composed of the union of the fields in WDPSender and 
WDPReceiver where the ether interface is shared between the two processes. 

WDP = App_to_WDP : f if o [Data] X 
WDP_to_App : f if o [Data] x 
linksender : Linklnterf ace x 
linkreceiver : Linklnterf ace x 
ether : Etherlnterf ace. 


19 



The WDP? transition relation is defined as follows: 

WDP?(s, n : WDP) = WDPSender ?(s s ,n s ) 

A s‘WDP_to_App = n‘WDP_to_App 
A s‘linkreceiver = rfilinkreceiver 

V 

WDPReceiver?(s r , n r ) 

A s‘App_to_WDP = n‘App_to_WDP 
A s‘linksender = rfilinksender. 

As in the case of WDP || GDP, the projections from a WDP state into a WDPSender state and 
into a WDPReceiver state are defined such that the input and output channels of the ether 
interface in the sender process are connected, respectively, to the output and input channels 
of the ether interface in the receiver process: 

s r ‘ether‘input = s s L ether 1 output, 
s r ‘ ether 1 output = ether 1 input, 
rir ether 1 input = n s ‘ether‘output, 
rir ether 1 output = n s £ ether‘input. 

The system GDP is defined in a similar way: 

GDP = App_to_GDP : f if o [Data] X 
GDP_to_App : f if o [Data] x 
winsender : WinSender x 
linksender : Linklnterf ace x 
winreceiver : WinReceiver x 
linkreceiver : Linklnterf ace x 
ether : Etherlnterf ace. 

The GDP? transition relation is defined as follows: 

GDP?(s, n : GDP) = GDPSender?(s s , n s ) 

A s‘GDP_to_App = n‘GDP_to_App 
A ^‘winreceiver = n‘winreceiver 
A s‘linkreceiver = n‘linkreceiver 

V 

GDPReceiver?(s r , n r ) 

A s‘App_to_GDP = n‘App_to_GDP 
A s‘winsender = n‘winsender 
A Alinksender = n‘linksender. 


20 



Proving invariants on transition systems, such as WDP and GDP, are routine in the theo- 
rem proving community. It usually entails the transformation of the initial invariant to an 
inductive form, i.e., a stronger invariant that can be proved by induction. 

The main difficulty remains the finding of auxiliary invariants that enable the inductive 
proof of the original invariant. For WDP and GDP the problem is further complicated by the 
fact that we have to consider the full protocol stack and all possible interleavings between the 
sender and receiver processes. The number of interleavings for each system is significantly 
lower than for the composed system WDP || GDP, 21 cases for WDP and 31 cases for GDP, but 
it is still a tedious task. For each one of these cases we have to prove that if an invariant is 
satisfied at step n, it is also satisfied at step n + 1. This is a considerable amount of work 
even though most of the cases can be easily discharged by using general properties of bags, 
queues, and bounded buffers. 

To automate the verification task, we have defined a set of proof strategies that unfold 
the transition relations WDP? and GDP? and discharge the easy cases of inductive proofs. Even 
in the cases where the strategies do not succeed, they generate enough information to assist 
a developer in finding weaker invariants. The strategies can be applied to discrete transition 
systems defined in PVS using Rusu’s theories, but are particularly suitable for protocols that 
use data structures such as bags, FIFO queues, and bounded buffers. 

Theorem 1. WDP_sound is an invariant on WDP. 

Proof Sketch. The proof that WDP.sound is an invariant of WDP only requires two proof com- 
mands. The first command is our strategy discharge-inv, which automatically proves 20 of 
the 21 inductive cases. The unproven case suggests an auxiliary invariant that states that all 
WDP frames in the link layer and in the ether belongs to So‘App_to_WDP. Once this invariant 
is added as a lemma to the theory, the proof is finished by using our strategy use-inv. To 
prove the auxiliary invariant, we follow the same approach, which suggests the new invariant: 

s‘WDP_to_App C so‘WDP_to_App. 

This new invariant is automatically discharged by discharge-inv. □ 

Theorem 2. GDP_sound is an invariant on GDP. 

Proof Sketch. The soundness proof of GDP is considerably more complicated than the sound- 
ness proof of WDP, but the general method is the same. We use our strategy discharge-inv 
to eliminate the easy cases and we add new invariants to discharge the unproven cases via 
use-inv. We iterate this approach on the new invariants. In total we have added 6 auxiliary 
invariants as lemmas, including the following relations between the sender’s and receiver’s 
windows: 

• The counter of received messages is less than or equal to the counter of sent messages: 

s‘winreceiver‘lr < s‘winsender‘ns 

• The counter of delivered messages is less than or equal to the counter of sent messages: 

s‘winreceiver‘nd < s‘winsender‘ns 
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• The largest sequence number for which an acknowledgment has been received is less 
than or equal to the counter of the sent acknowledgments: 

s‘winsender‘na + last_true(s‘winsender‘ackd) < s‘winsender‘la, 

where the function last_true returns the difference between s‘winsender‘na and the 
largest sequence number for which an acknowledgment has been received. 


□ 

As a point aside, we note that the invariants we have discussed in this section involve 
relationships between the sender and the receiver processes. There are many relationships 
that are local to either the sender or the receiver. For instance, the property that states that 
the index of the next message to be sent is greater than or equal to the index of the next 
message waiting to be acknowledged, i.e., s‘winsender‘na < s‘winsender‘ns, only concerns 
the sender process, and the property that states that the index of the next message to be 
delivered is greater than or equal to the index of the last message to be acknowledged, 
i.e., s‘winreceiver‘la < s‘winreceiver‘nd, only concerns the receiver process. As these 
properties can be described solely in terms of either GDPSender or GDPReceiver, they can 
be easily encoded using the PVS’s dependent type system and automatically discharged by 
the type checker. 

5.3 Proving Liveness for GDP 

The soundness property for GDP that was proved above corresponds to a safety property. We 
now consider a liveness property for GDP. While a soundness property states something bad 
does not happen, liveness states that something good will eventually happen. In the case of 
a sliding window protocol, liveness means that messages sent from the sender will eventually 
arrive at the receiver. Yet there are some complications to resolve. If some data is never sent, 
then it would be difficult to see what liveness property for GDP could be formulated under 
such conditions. Consequently, liveness properties are formulated under the assumption that 
the system behaves in a ‘fair’ manner. For GDP, the fairness property says that all messages 
in the App_to_GDP queue are eventually sent. That is, for every message in App_to_GDP, it 
is eventually the case that a state is recorded where each message has been sent. Since it 
is an invariant that ns always points to the next item to be sent in r 0 ‘App_to_GDP, we can 
state the fairness property as saying that given any run of the protocol, for every sequence 
number m < ro‘App_to_GDP ‘ length, the run records a state where ns > m. This is stated 
formally as follows: 


fair[(run)] = A(r : (run)) : V(m : below(r 0 ‘App_to_GDP < length) : 
3 (n : Nat) : /yCwinsender'ns > m. 


In principle, the liveness property should state that all messages that are sent are even- 
tually received. Yet this is not possible to prove given our assumption that App_to_GDP is 
of finite length. To see why, recall that the sender maintains a sliding window with size 
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sw and that the protocol ensures that all data with sequence numbers below na have been 
delivered. The invariant na < ns < na + sw relates the values of na and ns. If the fairness 
condition is satisfied, that is all of the data in the App_to_GDP queue has been sent and 
ns is equal to the length of the queue and the value of na is undetermined (except for the 
relation governed by the invariant), then based on the knowledge of the sender, we can only 
prove that the first 0, . . . , r'f/App to GDP ‘ length — sw items eventually arrive at the receiver. 
Consequently, our liveness property says that all data with a sequence number less than 
rVApp.to.GDP 1 length — sw eventually arrive at the receiver. Formally, this is expressed as 
a predicate on the runs of the protocol as follows: 

live [(run)] = A(r : (run)) : V(m : below(r 0 ‘App_to_GDP ‘ length - sw) : 

3(n : Nat) : ry/winreceiver ‘nd > m. 


Note that it is an invariant that 

nd = r n ‘GDP_to_App‘ length 

so the predicate expresses the desired property that for a given run it is eventually the 
case that all the messages with sequence numbers less than ro‘App_to_GDP ‘ length - sw are 
placed in the GDP_to_App queue. 

Several lemmas aide in the task of showing liveness follows from fairness. The predicate 
fair.auxl says that for all data with a sequence number less than r 0 ‘App_to_GDP ‘ length — sw 
it is eventually the case that the sender knows that these sequence numbers have been 
delivered. 

fair _auxl [(run)] = A(r : (run)) : V(m : below(ro‘App_to_GDP ‘ length - sw) : 

3(n : Nat) : r n ‘ winsender ‘na > m. 


The following lemma says that fair auxl follows from fair: 

Lemma 1. V(r : (run)) : fair=> fair^auxl. 

Proof Sketch. The crux of the proof is to skolemize the variable m in the consequent, which 
has a type 0 <m< ro‘App_to_GDP‘ length - sw, and then instantiate m in the antecedent, 
which has a range 0 < m < r 0 ‘App_to_GDP ‘ length, to m + sw. Applying the invariant 
na < ns < na + sw yields m + sw < ns < na + sw from which we can conclude m < na. □ 

Recall that the receiver maintains a pointer la indicating that all sequence numbers 
below la have been acknowledged. The predicate fair_aux2 says that for any given run, 
for all sequence numbers less than ro‘App_to_GDP f length - sw there is a state where these 
sequence numbers have been acknowledged. 

fair aux2[(run)] = A(r : (run)) : V(m : below(ro‘App_to_GDP‘ length - sw) : 

3(n : Nat) : ry/winreceiver'la > m. 


The next lemma relates the sender and receiver saying the fair_aux2 follows from fair_auxl. 
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Lemma 2. V(r : (run)) : faimauxl =>■ faimaux2 

Proof Sketch. The lemma follows from the antecedent and the invariant that na < la □ 
The liveness theorem states that liveness follows from fairness 
Theorem 3. V(r : (run)) : fair=> live 

Proof Sketch. The result follows from the above lemma. □ 

5.4 Proving Invariants on WDP || GDP 

We have seen that WDP_sound is an invariant of WDP and that GDP_sound is an invariant of 
GDP. However, onr verification objective is to show that both of them are also invariants of 
WDP || GDP. This goal could be trivially achieved if WDP and GDP were completely independent. 
They are not. As illustrated by Figure 3, WDP and GDP share the link layer and ether interfaces. 

In order to prove that a predicate is an invariant of a composed system, such as WDP || 
GDP, we develop a general theory of asynchronous composition of transition systems where 
invariants on one system can be lifted to the composed system. To this end, we consider that 
the state of a transition system consists of a private state and a shared state. The state of 
the composed system has a copy of the private states of each transition system but only one 
shared state common to both of them. When the composed system performs a transition 
in one of the constituent parts of the system, the private state of the other system remains 
unchanged. 

We define an abstraction a of a transition system T as a function that maps states into 
states such that 

1. if so is an initial state in T, then a(so) is also an initial state of T, and 

2. if (s n ,s n+ i) is a transition in T, then (a(s n ), a(s n+ i)) is also a transition in T. 

Given this definition, we formally prove the following theorem: 

Theorem 4 (Invariant Left-Lifting). Let P be an invariant of a transition system T x . The 
predicate P is an invariant of the transition system T) || T 2 if there is an abstraction a of 
Ti such that the followmg conditions are met: 

1. P is orthogonal to a, i.e., P(a(s)) implies P(s), and 

2. under the abstraction a, T 2 does not interfere with 7j, i.e., if (s n ,s n+ 1 ) is a transition 
in T 2 , then (a(s n ), a(s n+ i) is a transition in Ti. 

Proof Sketch. Consider an arbitrary trace so, . . ■ , s n in Ti || T 2 . We will show that P holds 
in s n . First, we show that cc(so), . . . , a(s n ) is a trace in Ti. There are two cases: 

1. The transition (sj,s i+ i) is a Ti transition. In this case, (a(sj) — > a(sj+i)) is also a Ti 
transition since a is an abstraction. 

2. The transition (sj,s i+ i) is a T 2 transition. In this case, (a(sj), a(sj+i)) is also a T\ 
transition since T 2 does not interfere with T\. 
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Therefore, a(so), • • • , a(s n ) is a trace in Tf. Since P is an invariant on Ti, P holds in a(s„). 
Since P is orthogonal to a , P holds in s n as well. □ 


A symmetric theorem for the right transition system can be proved in a similar way. 

Theorem 5 (Invariant Right-Lifting). Let P be an invariant of a transition system T 2 . The 
predicate P is an invariant of the transition system T x || T 2 if there is an abstraction a ofT 2 
such that P is orthogonal to a, and under the abstraction a, 7\ does not interfere with T 2 . 

For the case of the distributed system WDP || GDP, the queues App_to_WDP and WDP_to_App 
are private to WDP. The queues App_to_GDP and GDP_to_App, and the fields winsender and 
winreceiver are private to GDP. All the other fields, i.e., the link and the ether interfaces, 
are shared. 


Theorem 6 (WDP Soundness). WDP_sound is an invariant on WDP GDP. 


Proof Sketch. We consider an abstraction a. 

a^(s‘link‘GDP_to_Link) = 
a w (Alink‘Link_to_GDP) = 
(Aether 1 input) = 
a w (s‘ ether 1 output) = 


(s : WDP) such that a w (s) = s in all fields but: 

empty, 

empty, 

remove_gdp(s‘ ether ‘input), 
remove_gdp(s‘ ether ‘output), 


where empty is the empty queue and remove_gdp removes all GDP frames from a multiset. 
Then, we prove that a w is indeed an abstraction of WDP, that WDP.sound is orthogonal to 
a w , and that, under a w , GDP does not interfere with WDP. Therefore, by theorems 1 and 4, 
WDP.sound is an invariant on WDP || GDP. □ 

Theorem 7 (GDP Soundness). GDP_sound is an invariant on WDP || GDP. 

Proof Sketch. We consider an abstraction a g (s : GDP) such that a g (s) = s in all fields but: 


cc g (sTink‘WDP_to_Link) = 
cc g (sTink‘Link_to_WDP) = 
a ff (s‘ether‘ input) = 
a 9 (s‘ether‘output) = 


empty, 

empty, 

remove_wdp(s‘ ether 1 input ) , 
remove_wdp(s‘ ether 1 output), 


where remove.wdp removes all WDP frames from a multiset. Then, we prove that a g is 
indeed an abstraction of GDP, that GDP_sound is orthogonal to a g , and that, under a g , WDP 
does not interfere with GDP. Therefore, by theorems 2 and 5, GDP.sound is an invariant on 
WDP || GDP. □ 

As in the case of invariants, we have developed proof strategies to prove that a given 
function is an abstraction, and that the orthogonality and noninterference conditions are 
satisfied. 
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6 RELATED WORK 

Numerous variations of the basic sliding window protocol have been subjected to formal 
verification. Stenning [23] is likely to have been the first to discuss the correctness of such 
protocols. Virtually every study has focused on proving safety properties just as we have. 
Several case studies have been produced deriving sliding window protocols using the method- 
ology originated by Dijkstra’s school. Van de Snepscheut [8] transforms a sequential program 
while preserving its correctness and Hoogerwoord [12] applies a methodology for deriving 
multiprograms to derive a sliding window protocol. In both cases, the protocol assumes 
unbounded window size. Process algebras have also been used to manually verify one-bit 
sliding window protocols [25, 3]. 

Model checking has been applied to a number of sliding window protocols. Holzmann [10, 
11] verified both safety and liveness properties for a protocol with a window size of five 
and [14] did the same for a protocol with a window size of seven. Applying abstraction and 
model checking, Sthal was able to verify the a protocol with a window size of sixteen [22] . 

Others have also applied automated theorem provers to verify sliding window protocols. 
Cardell-Oliver used HOL to verify safety properties [4], A timed model was given in [7] and 
a safety property is verified using PVS. Rush [21] proved safety and liveness of a protocol 
with unbounded window size in PVS. Safety and liveness properties of a protocol with 
arbitrary finite window size employing modulo-arithmetic were verified using process algebra 
techniques with the assistance of the PVS prover in [1], 

The sliding window protocols verified in aforementioned efforts were considerably sim- 
pler than the sliding window protocol with block acknowledgment response that we have 
presented here. Only [1] also considers a protocol with arbitrary, but finite window size. 
Previous work considered the sliding window protocol acting in isolation rather than as a 
component in a protocol stack, which added considerable complexity to the proofs, but is 
required to accurately model the communication process. 

Concurrently executing programs are complex artifacts making it difficult to reason about 
their correctness. For parallel programs with shared variables, the classical theory of Owicki 
and Gries [18] was the first breakthrough for reasoning about the correctness of parallel 
programs having shared variables, but the theory is not compositional. Assume-Guarantee 
methods modify the theory to be compositional [16, 13, 15, 26]. Rushby [20] has developed 
a version of an assume-guarantee rule for use in the verification of timed reactive systems. 
Charpentier [6, 5] has recently explored the composition of invariants for concurrent systems. 
In this research the authors explored both invariants satisfied by every component of the 
composed system as well as situations similar to the one we explored where an invariant in 
the composed system is satisfied by one component of the composed system. Our approach 
is not as powerful as assume-guarantee methods, but is largely mechanizable as we have 
shown here. We believe that our method is suitable for composition of protocol stacks that 
share the lower communication layers. 

7 CONCLUSION 

In this paper, we have presented the formal verification of a communication protocol between 
an airborne vehicle and a ground station. The protocol stack is structured as an application 
layer, transport layer, and link layer. Separate protocols have been presented that satisfy 
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the safety requirements of weak delivery and guaranteed delivery. The model for each layer 
is described in some depth as is the composition of the layers. In addition, we have presented 
the theorems that characterize the functional correctness of the proposed protocol. 

We aim to support an iterative protocol design process and a rapid prototyping environ- 
ment. To this end, we propose a hierarchical verification approach where safety properties 
are first proved for the individual components of the protocol and then lifted to the composed 
system. This approach is largely mechanizable and we provide several proof strategies that 
automate most of the verification burden. 

Our formal development in PVS consists of 28 theories and 129 lemmas. In total, there 
are 1758 lines of specification, 4987 lines of proofs, and 712 lines of strategy code. Most of 
these theories concern the specification and verification of the proposed protocol. However, 
we also provide a general theory for the asynchronous composition of transition systems 
and general strategies to prove invariants, abstractions, and the orthogonality and noninter- 
ference conditions. We believe that this verification framework can be applied to a family 
of distributed protocols, particularly those protocols that use data structures such as bags, 
FIFO queues, and bounded buffers. 
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